mytimeatportiafandomcom-20200222-history
User blog:SuperSarcosmic/Disappearing message bug and mobile compatibility on the current Fandom platform
This is a brief overview of some of the errors or difficulties that can be encountered on the present version of the Fandom (Wikia) platform, as well as methods to deal with them. It's pertinent to specify "present version" because there have recently been announcements about an updated Mediawiki and such. For further reading, see the following announcements: *''Fandom is upgrading to a modern version of MediaWiki'' *''Our first update on the new platform'' *''The first specifics on the Unified Community Platform'' More Fandom-related issues may be noted here as I come across them. __TOC__ User wall messages not always sending There's a bug where messages, such as messages posted on user message walls, may occasionally disappear. I believe it's a browser cache bug where Fandom can't save the message if one of the users' displayed edit count doesn't match up with their actual edit count, so your message doesn't send. This is part of the reason we moved to Discord for wiki discussions. ;Method to avoid the bug #Add ?action=purge to the message wall's url and enter it to purge the page's cache and reload the page. #Copy your entire message to your clipboard before sending. #Send message #Check if message has sent. If it disappears and does not immediately appear on the page, then it has not sent; repeat step 1 and paste message into text box to try sending it again. This bug will persist until Fandom shifts this wiki onto the new Unified Community Platform (UCP). During the shift, the previous version of forums, talk pages, and comment sections will be retired and replaced with a more functional alternative. (User message walls and profiles will also be changed, but replacements will migrate user information and message wall messages over.) Mobile compatibility Certain elements may display differently, not display at all, or not function correctly on mobile. Caution should be exercised when designing templates, article layouts, and tables so that the mobile version of the site does not lack information or important functionality that is readily available on the desktop version. The mobile preview in the editor is inaccurate, and use is discouraged. For accurately testing templates and such on mobile, the public Sandbox page or a mobile device or emulation can be used. (More details are in the Accurate mobile previews section.) Things that do not function as intended These lists are under construction. Feel free to ask for more details about any particular thing, though my knowledge is limited. Please see The Table on my profile for some of the less-pressing issues with templates and such not displaying properly on mobile, such as infoicons linking to image files instead of item pages. Relevant information from The Table as well as links to related help pages will eventually be further worked into this blog. ;Things that do not appear at all *Templates categorized as Notices (a.k.a. tophats or alerts) *Any kind of hover text or hover element *Custom text or image alignment or sizing *Custom text, background, or theme colors (including when is used) *Table sort function *Polls ;Things that function incorrectly *Templates categorized as Infoicons **Tapping on icon takes user to direct image file, not article **Any text links that are part of the infoicon are not displayed on mobile; re-categorizing the Infoicon template as a Data template will allow text links to appear on mobile * , , and tags will all display their contents as if they were a basic table, and will not have their special features **Content in tags will be displayed in a table, though they will scroll off the edge of the screen in a single line, rather than preserving paragraphs or linebreaks ;Things that appear differently These things display their contents, but are styled differently due to the Mercury (mobile) skin forced upon them. * s * tags will be formatted as if they were using *Tables (see below) *Images (see below) Tables Tables with too many columns are terrible for navigation on mobile, as they will stretch beyond the bounds of the phone screen and it can become difficult to reference columns or rows beyond the boundaries. Tables that have many columns should be broken up into smaller tables or otherwise have the information be condensed, if possible. Table widths on desktop mode Additionally, if a table is located high in the page and is likely to be next to an infobox, setting such tables to a maximum width of 55% allows the table to sit next to the infobox without being pushed under it on a variety of desktop display resolutions. It should also be noted that table widths should be defined by percentages, rather than pixels, allowing for tables to automatically scale to fit various screen sizes on desktop mode. These are the results of my findings earlier this year: *A table at 60% width in a fullscreened window did fine next to an infobox on 1600x900 display resolution, though with the following resolutions, the table got kicked below the infobox: **1280x768 **1280x720 **1024x768 **1024x600 **800x600 *A table at 55% width fit next to the infobox as desired on all previously mentioned display resolutions except for 1024x720 and 1024x600. **These fairly small, boxy resolutions are unlikely to be used by players of , as screens have tended towards being more widescreen as well as higher resolution for over a decade now. Therefore, I do not consider them to be a significant issue, and 55% width tables seems to be reasonable. Images Images will change size and position in mobile mode based on their displayed size on desktop mode. Currently, most images on this wiki are displayed above 30px, other than images displayed using , , , and any template manually modified to display the image at 30px or below. This means that images such as infobox or thumbnail images will typically enlarge to fit the width of the screen, and images in table cells will scale to fit the width of the cell. Multiple images formatted in gallery tags will automatically scale so that they sit neatly next to each other. (Further testing is needed; this is the extent of what I know and can recall at the moment.) Accurate mobile previews The mobile preview function in the editor does not accurately represent or function like a true mobile experience. So, the mobile version of the site can be accurately viewed and interacted with on a desktop environment by the following methods: ;Method 1 (my preferred method) This accurately emulates a smartphone screen, but only in the tab that the inspection console was called. Specific device resolutions (ex. iPhone 6/7/8, iPhone X, Galaxy S5, Pixel 2 XL, iPad Pro) can be chosen above the emulation. #Right-click the page and select Inspect from the dropdown menu or type Ctrl+Shift+I #Select the icon that looks like a smartphone and tablet in the toolbar of the console that pops up. #Refresh the page. #To exit this mode, click on the X in the upper right of the inspection console or type Ctrl+Shift+I again, then refresh the page. ;Method 2 This also accurately emulates a smartphone screen, but the screen will instead fill the size of the browser. #Append ?useskin=mercury to the end of any url on the wiki, then enter the modified url. #*The exception to this is on userpages, user subpages (including user sandboxes), or project pages. Such pages will always have the desktop view enforced, and will replace attempts to use ?useskin=mercury (mobile layout) with ?useskin=oasis (desktop layout). #To exit this mode, delete the ?useskin=mercury part from the url or replace "mercury" with "oasis", then refresh the page. Category:Blog posts